This is a guide to clone a Debian server from a dedicated machine to another one. It is using rsync.
I've been running a dedicated server (a Dedibox SC) for 6 years, it's been successfully serving my websites, emails and a few other services. Today, I needed to migrate it a newer machine (still a Dedibox: Dedibox SC 2016).
Specifications of the two servers:
•.Old server: Dedibox SC (2011); CPU: VIA Nano processor U2250 (1.6GHz Capable); RAM: 2 GB; HD: 150 GB; Datacenter: DC2 (Paris, France); 14.99€/month + VAT.
•.New server: Dedibox SC 2016; CPU: Intel Atom CPU C2338 @ 1.74GHz; RAM: 4 GB DD3; HD: 1TB SATA; Datacenter: DC5 (Paris, France); Bandwidth: 1 GB/s; 8.99€/month + VAT.
Both machines are running the same CPU architecture (x86_64) (this is important for the migration process). The new machine runs a newer version of the CPU, so more instruction sets are supported (it prevents running into the problem of binaries compiled for different instruction sets).
I didn't want to manually replicate all my configurations and crons from one machine to another, so I chose the easiest way: Cloning the existing server to another machine (using rsync).
I am going to use rescue mode as it gives me the guarantee that the original files won't be modified while being transferred (so I won't have to deal with corrupted files - like MySQL databases which could be corrupted during the transfer otherwise).
You could probably do it on a running server if you want to reduce the downtime, in this case do a first rsync pass (long) and when it's done shutdown all your services (especially MySQL) and do another rsync pass (it'll only copy the files that have been modified in between the two runs - which should be pretty fast).
Some steps are specific to using a Dedibox (I'll mark these steps), feel free to skip or adapt them.
•.Both CPUs should use the same architecture (example: x86_64).
•.Destination server should have enough free space to receive all the original server's files (but it doesn't matter if partitions don't have the same size).
•.Have access to some kind of rescue mode (at least on the destination server).
I am going to refer to the source server as the old server and to the destination server as the new server.
Feel free to adapt or skip the steps marked [Dedibox specific].
•.[Dedibox specific]: Log into the online.net console.
•.Install a fresh Debian version to the new server (ideally the same version as your old server).
•.Hint: use cat /etc/debian_version and uname -a to know your Debian version.
•.Note: Partition sizes don't have to be the same, but the destination partition must be large enough to receive all the files from the old server.
•.Note: This step creates the partitions on your new server; creates the /etc/network/interfaces and /etc/fstab configuration files working with your hardware; and (for Dedibox users) allows online.net to keep track that there is a Debian system installed on this computer.
We're going to copy the file in offline mode to prevent them to be modified while being transfered.
•.Steps to follow on your [Old Server]:
•.Start your old server into rescue mode (Ubuntu preferred).
•.ssh into your old server (in rescue mode).
•.Note: (for Dedibox users) if the password from the online.net console doesn't work, wait for a few minutes and try again, it sometimes take time.
sudo su
mkdir /mnt/readonly
•.(replace /dev/sda2 by your root partition):
mount -o ro /dev/sda2 /mnt/readonly/
•.Note: mounting as readonly to prevent erasing things by mistake.
•.[Dedibox specific] (replace /dev/sda1 by your /boot partition):
mount -o ro /dev/sda1 /mnt/readonly/boot/
cd /mnt/readonly/
nano /etc/sudoers
•.Add this line at the end of the file (replace YOUR_USERNAME by your local unix username):
•.YOUR_USERNAME ALL= NOPASSWD:/usr/bin/rsync
•.Note: put it at the very end of the file, otherwise it wouldn't work - this will allow you to execute rsync as root through ssh later on.
•.Save the modifications and close the file.
We're going to prepare your new server to receive the copied files.
•.Steps to follow on your [New Server]:
•.Start your new server into rescue mode (Ubuntu preferred).
•.ssh into your new server (in rescue mode)
•.Note: (for Dedibox users) if the password from the online.net console doesn't work, wait for a few minutes and try again, it sometimes take time.
sudo su
mkdir /mnt/new_server/
•.Note: CAREFUL TO EXECUTE THIS ONLY ON THE NEW SERVER (SO YOU DON'T ERASE EVERYTHING ON YOUR OLD SERVER!)
•.(replace /dev/sda2 by your root partition):
mount /dev/sda2 /mnt/new_server/
•.Note: CAREFUL TO EXECUTE THIS ONLY ON THE NEW SERVER (SO YOU DON'T ERASE EVERYTHING ON YOUR OLD SERVER!)
•.[Dedibox specific] (replace /dev/sda1 by your /boot partition):
mount /dev/sda1 /mnt/new_server/boot/
cd /mnt/new_server/
screen
•.Note: start a screen so you can ssh back and type screen -r to resume your session if you get disconnected.
•.(replace YOUR_USERNAME and YOUR_OLD_SERVER_IP by the relevant information):
rsync -aHAXSz --delete --info=progress2 --numeric-ids -e "ssh" --rsync-path="sudo rsync" --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found","/etc/fstab","/etc/udev/rules.d/*","/etc/network/*","/lib/modprobe.d/*"} YOUR_USERNAME@YOUR_OLD_SERVER_IP:/mnt/readonly/ /mnt/new_server/
•.Don't forget to keep the slashes a the end, they are important!
•.CAREFUL: This will erase all the files present on your new server and replace them by the files currently present on your old server, be sure that you typed the command correctly and that it's really what you want to do before executing it!
•.Note: you can use -v instead of --info=progress2 if you want a more verbose output.
•.Note: --delete will delete all of your files in the destination server, be sure that it's really what you want to do.
•.Note: Folders that we don't want to copy are excluded.
•.Note: --numeric-ids should do a better job at preserving users/groups (as it won't try to map the numerical users to your currently running rescue-mode system.
•.Note: you can read man rsync to know what the other flags are doing, I've mostly followed the recommendations from the arch linux wiki and from this blog post.
•.Note: this step should take a while (from 30 minutes to a few hours depending on your connectivity and on how much data you have to transfer (from a few GB to several hundreds GB maybe)).
•.Note: if the command doesn't work, try removing ,"/lib/modprobe.d/*", and in this case make a backup of the /mnt/new_server/lib/modprobe.d/ files from your clean installation for a later use (to replace them later if needed).
Wait for a while until it's done...
If you get disconnected you can still reconnect to your new server and type screen -r.
Now you need to change the migrated configuration to match the hardware of your new server.
Once rsyncing has completed:
•.Steps to follow on your [New Server]:
•.Replace the network interface listed in the file (probably eth0) by the one you get from running ifconfig -a on your new server (likely eth0 or enp1s0). (Don't modifiy the lo interface, it's your loopback interface. Modify the other one.)
•.Save the modifications and close the file.
nano /mnt/new_server/etc/hosts
•.If your old server's ip address is present in your hosts file, replace it by your new server's ip address.
•.Save the modifications and close the file.
Once rsyncing and editing configuration files is done, setup grub on your new machine:
(At this point, your root filesystem and boot filesystem should still be mounted into /mnt/new_server and /mnt/new_server/boot)
•.Steps to follow on your [New Server]:
•.Run the following commands to install grub:
mount --bind /proc /mnt/new_server/proc
mount --bind /sys /mnt/new_server/sys
mount --bind /dev /mnt/new_server/dev
mount --bind /run /mnt/new_server/run
chroot /mnt/new_server
grub-install /dev/sda
update-grub
Now you're ready to test if your new system behaves properly:
•.Steps to follow on your [New Server]:
•.Reboot your new server into normal mode (wait a few minutes for everything to start properly).
•.ssh into your new server.
•.Note: connect by the ip as you probably didn't update the DNS entries for your hostname to point to your new ip yet :)
•.Check logs to see if everything look alright (mainly into /var/log/syslog and check if you can see obvious errors).
•.Test your websites / services if you can (like by directly accessing them directly by your server's ip address).
If everything works, then you can edit your old DNS to point to your new server's ip. The update usually takes up to 24 hours for the changes to propagate properly.
Once your DNS are updated and propagated (usually the next day), you can test again that all your services are working properly.
You should probably shutdown your old server at this point to prevent clients from connecting to your old server. Depending on how your services are configured, this will prevent you from getting data inconsistencies where new emails arrive on your old server or new user accounts are being created on your old database (remember that DNS propagation can take time).
For Dedibox users: You can also update your reverse DNS from the console and enable your ftp backup space if you want (just remember to update your crons / backup scripts to point to your new ftp host / username / password combination).
If after a few minutes you still can't ssh into your new server, here are a few steps so you can try to figure out what is going on:
•.Steps to follow on your [New Server]:
•.Restart your new server into rescue mode.
•.Mount your partition again (same step as before).
•.See if syslog has been modified recently (it means your server did boot, but failed later):
ls -al /mnt/new_server/var/log/syslog
•.If the modification time is older than a few minutes ago, it means that your server didn't boot at all.
•.If it's the case, look into re-installing grub (it's probably this step which failed). Especially, be sure that you've mounted your /boot partition correctly before running grub-install /dev/sda and update-grub.
•.You can also look /mnt/new_server/etc/fstab and check if the UUIDs are matching the ones of your new hardware (ls -l /dev/disk/by-uuid/). If not, run the same command on your old server and manually replace your old UUIDs by the new ones.
•.If your system booted properly but you still couldn't ssh into it, read your syslog file to try to understand what is going on:
less /mnt/new_server/var/log/syslog
•.At this point it's probably a network error (or a driver error), try to look for the words ifup, eth0, eth1, enp1s0, network, failed, or error. Maybe something like:
Jul 11 21:38:16 hera ifup[414]: Cannot find device "eth0"
Jul 11 21:38:16 hera ifup[414]: ifup: failed to bring up eth0
•.If it's a network error:
•.Look into /mnt/new_server/etc/network/interfaces (probably a wrong interface name, a bad ip address, gateway, netmask, or something like that). You can also run ifconfig -a and check if your interface / ip are matching the ones in your network/interfaces file.
•.Try to remove /mnt/new_server/etc/udev/rules.d/70-persistent-net.rules (or other similar files - this file maps hardware mac addresses to network interfaces, if the ones from your old server have been transferred by mistake it could be the source of the problem).
Here are more websites if you run into troubles and want to read more about the various methods:
•.Main sources (rsync):
•.http://positon.org/clone-a-linux-system-install-to-another-computer
•.https://wiki.archlinux.org/index.php/Rsync#As_a_backup_utility
•.sudo over rsync tip: https://crashingdaily.wordpress.com/2007/06/29/rsync-and-sudo-over-ssh/
•.--numeric-ids explanation: https://tanguy.ortolo.eu/blog/article19/rsync-options
•.Alternative methods (I haven't tested these ones):
•.Additional sources: